Fixed in commit 4c74e3e. The diagnostic message is now syntax-neutral: "string concatenation inside a loop allocates O(n) strings and O(n²) total bytes; use strings.Builder instead". All // want patterns in testdata updated accordingly.

Fixed in commit 4c74e3e. Removed the ForStmt branch from isLoopScopedIdent — for-init variables run once before the loop and carry state across all iterations, so they are genuine accumulators and must be flagged. Only RangeStmt Key/Value remain exempted. Added a regression test case for for s3 := ""; ... that verifies it is now flagged.

[/tdd] The loop-scope guard is only applied to the ASSIGN form (x = x + y), not to ADD_ASSIGN (x += y). A range-value or for-init variable using += would be falsely flagged, creating a behavioral asymmetry between the two forms.

for _, line := range parts {
    line += " suffix" // would be flagged — but line is a per-iteration rebind
}

@copilot please address this.

Fixed in commit 89abd77. The scope guard (isLoopScopedIdent + isLoopBodyLocal) is now applied uniformly whenever the LHS is a plain *ast.Ident, regardless of whether the token is ADD_ASSIGN or ASSIGN. A testdata case for line += " suffix" on a range-value variable confirms it is no longer flagged.

[/diagnosing-bugs] For ADD_ASSIGN, assign.Lhs[0] is used directly without checking that len(assign.Lhs) == 1. A multi-LHS assignment like a, b += ... is syntactically invalid in Go, but the guard on line 61–63 (applied only to ASSIGN) makes the intent asymmetric and harder to reason about.

case token.ADD_ASSIGN:
    if len(assign.Lhs) != 1 {
        continue
    }
    lhsExpr = assign.Lhs[0]

@copilot please address this.

Fixed in commit 89abd77. Added len(assign.Lhs) != 1 guard to the ADD_ASSIGN case, making it symmetric with the ASSIGN branch.

[/tdd] The comment says "direct self-referential form only — x = x + a + b is out of scope", but this is not tested. The x = x + a + b case parses as BinaryExpr{X: BinaryExpr{X: x, Y: a}, Y: b}, so binExpr.X would be a *ast.BinaryExpr, not *ast.Ident — meaning it would silently fall through. A testdata case would document and lock this boundary.

// x = x + a + b (chained) – out of scope, not flagged.
for _, p := range parts {
    accum = accum + p + " extra" // should NOT be flagged
}

@copilot please address this.

Added a testdata case in commit 89abd77: accum4 = accum4 + p + " extra" (chained form) is present in good() with no // want annotation, which the test framework enforces must produce no diagnostic. The comment explains why: binExpr.X is itself a BinaryExpr, not an *ast.Ident, so the self-referential check fails silently.

False positive: a fresh var accum string declared inside the loop body each iteration is misclassified as a cross-iteration accumulator and gets flagged.

for _, p := range parts {
    var accum string
    accum = accum + p
    _ = accum
}

Fixed in commit 89abd77. Added isLoopBodyLocal which uses pass.TypesInfo.ObjectOf(ident).Pos() to check whether the variable's declaration falls inside the loop body (body.Lbrace .. body.Rbrace). A testdata case var local string; local = local + p inside a range loop confirms it is not flagged.

The new x = x + y detection only supports a simple identifier LHS, unlike += which accepts any lvalue — an inconsistency that silently drops coverage for common accumulator patterns.

The ASSIGN path intentionally restricts to plain identifiers. Generalising to struct-field and map/slice-index lvalues (s.Field = s.Field + y, m[k] = m[k] + y) requires structural AST comparison and is explicitly out of scope for this PR (noted in the PR description as "direct self-referential form only"). The ADD_ASSIGN path already catches field/index accumulators via the existing += form; this gap is narrow in practice. A follow-up issue can track the generalisation if desired.